Open Bug 1842541 Opened 2 years ago Updated 2 years ago

Consider blocking all unsigned DLLs

Categories

(External Software Affecting Firefox :: Other, enhancement)

Desktop
Windows
enhancement

Tracking

(Not tracked)

People

(Reporter: yannis, Unassigned)

References

Details

Bug 1841751 and bug 1823412 are examples where malware injects DLLs into Firefox processes. In bug 1841751, the DLL seems unsigned. I also confirmed that I can inject my own unsigned DLL without any problem.

I feel like in 2023 we should be safe to block all unsigned DLLs:

  • possibly behind a pref, to allow easy debugging (e.g. me playing with bug 1841751);
  • possibly only for recent versions of Windows if we discover old legit unsigned DLLs on older versions.

I would guess that most (if not all) injected unsigned DLLs these days are likely to be malicious, at least on recent machines. Of course we should first double check this guess by looking for counterexamples in untrusted modules telemetry (e.g., is the X-Mouse Button Control DLL signed? if not, can we interact with the developer so that they sign it?). Overall, it should improve the user experience (e.g. fewer ads shown by adware) and security (e.g. fewer data collected by malware without the user knowing).

OS: Unspecified → Windows
Hardware: Unspecified → Desktop
Summary: Block all unsigned DLLs → Consider blocking all unsigned DLLs
Type: defect → enhancement

Please make sure that third-party IMEs (such as ATOK) work with unsigned DLLs blocked.

(In reply to Yannis Juglaret [:yannis] from comment #0)

Of course we should first double check this guess by looking for counterexamples in untrusted modules telemetry

I was going to ask - is this something we have telemetry for?

You need to log in before you can comment on or make changes to this bug.